home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TeX 1995 July
/
TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO
/
tex-k
/
tex-k-archive.past
/
tex-k-archive.gz
/
tex-k-archive
/
000067_fj@iesd.auc.dk_Mon Oct 18 14:17:11 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1994-10-11
|
2KB
Received: from iesd.auc.dk by cs.umb.edu with SMTP id AA14911
(5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Mon, 18 Oct 1993 08:17:42 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA20197
(5.65c8/IDA-1.5/MD); Mon, 18 Oct 1993 13:15:41 +0100
Received: by loke.iesd.auc.dk id AA06288
(5.65c8/IDA-CLIENT/MD); Mon, 18 Oct 1993 13:17:11 +0100
Date: Mon, 18 Oct 1993 13:17:11 +0100
From: Frank Jensen <fj@iesd.auc.dk>
Message-Id: <199310181217.AA06288@loke.iesd.auc.dk>
To: karl@cs.umb.edu
Cc: tex-k@cs.umb.edu
In-Reply-To: <199310181053.AA16574@terminus.cs.umb.edu> (karl@cs.umb.edu)
Subject: Re: Speed of (recursive) search in the Kpathsearch library
Karl> Five directories is a lot better than 75.
Yes, it is a much smaller number, but we have to remember that one of
these five directories is the current directory (which is first on my
path) from where five files were read. The other seven files were
distributed evenly (2+2+2+1) in the other four directories. The first
time these directories are `hit', it will require searching
approximately half of the 75 directories. So an optimistic
expectation will be at most a factor of two of speed-up. And that is
only when we ignore the most time consuming task, namely setting up
the list of directories in the first place.
Karl> I think it's worth trying.
I agree, we should try everything that might help, since we cannot
rely on index files in all situations. But I'm afraid I'll have to
say that it won't suffice (or even be close) in situations where huge
directory hierarchies have to be searched. The Kpathsearch library is
effectively doing a `find' operation on the directory hierarchy, and
we all know what that means in terms of time and disk activity.
/Frank